% File:     srs.tex
% Author:   Ryan J. Bovorasmy
% Date:     2007-06-23
% Desc:     SRS Template, based on the MSOE SDL XML SRS template.
% Rev:      [2007-06-23, Ryan J. Bovorasmy] First major revision.
% Rev:      [2007-10-16, Ryan J. Bovorasmy] Updated template, made minor fixes.
% Rev:      [2007-10-17, Ryan J. Bovorasmy] Created the ProtoVitae SRS from template.
% Rev:      [2007-10-30, Ryan J. Bovorasmy] Added documentation for the different 
%                                 kinds of requirements used by this document.
% Rev:      [2008-01-12, Ryan J. Bovorasmy] Revised risks for cycle 3.
% Rev:      [2008-02-16, Paul Kratt] Revised risks for cycle 4.
% TODO:     Make changes to original template to reflect the above revisions.
%
\documentclass[letterpaper,10pt]{article}
\usepackage{graphics}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%% INSTRUCTIONS:
%%
%% This document can be used to create an SRS. It is meant to be used in
%% conjunction with a usecase template (usecase.tex).
%%
%% Certain sections (such as this one) are delimited with special comments.
%% These sections contain similar material, and should be treated as a group.
%%
%% Comments beginning with *** indicate that editing is necessary in that
%% area. Example:
%%
%% *** Section description. This section needs editing.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
%
% BEGIN COMMAND SECTION
% Do not edit this section unless you know what you are doing.
%
\newcounter{usecase}
\newcounter{flownumber}
\newcommand{\history}[3]%
{%
\hline
#1 & #2 & #3
}
\newcounter{goal}
\newcommand{\goal}[3]%
{%
\addtocounter{goal}{1}
\parbox{.75\textwidth}{
\begin{description}
  \item[\textbf{Goal \thegoal{}:}]~#1
  \item[\textbf{Advantage:}]~#2
  \item[\textbf{Metric:}]~#3
\end{description}
}
~\\{}
}
\newcounter{risk}
\newcommand{\risk}[5]%
{%
\parbox{.75\textwidth}{
\begin{description}
  \addtocounter{risk}{1}
  \item[Risk \therisk:] #1
  \item[Last Updated:] #2
  \item[Severity:] #3
  \item[Likelihood:] #4
  \item[Mitigation:] #5
\end{description}
}
~\\{}
}
\newcommand{\work}[4]%
{%
  #1 & #2 &%
  \parbox{.22\textwidth}%
  {#3} &%
  \parbox{.23\textwidth}%
  {#4}
}
%
% END COMMAND SECTION
%
%||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

%------------------------------------------------------------------------------
%
% BEGIN VARIABLE SECTION
%
%
% *** Enter the Project name here:
%
\newcommand{\projectname}{ProtoVitae}
%\newcommand{\abrvname}{ABBREVIATED PROJECT NAME}
%\newcommand{\totalname}{\projectname{} (\abrvname{})}
%
% *** Enter the author names here, separated by newlines:
%
\newcommand{\authors}%
{%
Kieran Easter\\
Adam Patterson\\
Ryan J. Bovorasmy\\
Paul Kratt\\
}
%
% *** Enter the current version of the document:
%
\newcommand{\version}{1.7}
%
% *** Enter the revision history here.
% The format of the history command is as follows:
%
% \history{NAME}{DATE}{BRIEF DESCRIPTION\\}
%
% Notice that a newline is REQUIRED after the description.
%
\newcommand{\revhistory}%
{%
\history{Ryan J. Bovorasmy}{2007-10-17}{Created SRS from template.\\}
\history{Ryan J. Bovorasmy}{2007-10-24}{Added team-created use cases, modified templates.\\}
\history{Ryan J. Bovorasmy}{2007-11-04}{Compiled complete document from entire team.\\}
\history{Kieran Easter}{2007-10-24}{Fixed Project Goals to make actual sense.\\}
\history{Ryan J. Bovorasmy}{2007-11-04}{Made revisions to complete document.\\}
\history{Ryan J. Bovorasmy}{2008-01-12}{Revised risks for cycle 3.\\}
\history{Paul Kratt}{2008-02-16}{Revised risks for cycle 4.\\}
\history{Paul Kratt}{2008-05-03}{Revised risks for cycle 6.\\}
}
%
% END VARIABLE SECTION
%
%------------------------------------------------------------------------------

%
% Do not mess with these header lines unless you know what you are doing:
%
\title{SRS for the \projectname{} Project}
\author{\emph{Prepared By:}\\{}\authors{}\\{}\\{}\emph{Document Version:}~%
\version{}\\{}\emph{Template Version:}~1.1}
\date{\emph{Last Modified:} \today}
\textwidth=6.5in
\oddsidemargin=0.0in

\begin{document}

\maketitle
\tableofcontents
\newpage

%
% *** Write a brief description of the project here:
%
\begin{abstract}
  The \projectname{} project aims to create a ``virtual petri dish'' in which educators, students, and interested individuals without previous experience in AI/AL theory and without engineering degrees can simulate biological evolution in a fun, faster-than-life, and graphics-intensive environment. As such, \projectname{} is meant to be a simplified AL (artificial life) environment.
\end{abstract}

%
% Do not alter this section:
%
\section{Revision History}
\begin{table}[htbp]
  \label{table:revhistory}
  \begin{tabular}{|l|l|l|}
    \revhistory
    \hline
  \end{tabular}
\end{table}

%
% This section contains a brief summary of the project.
%
\section{Brief}
%
% In general, nothing needs to be done with the executive summary,
% but you may want to read it over before publishing it.
%
\subsection{Executive Summary}
This Software Requirements Specification records agreements between the
\projectname{} development team (Team K.A.R.P.) and all applicable stakeholders regarding the internal
functionality and external interfaces of the \projectname{} system.
This specification will form the
basis for the design, implementation, and testing of the \projectname{} system and
all related subsystems, as defined by this document.
%
% *** Enter a full project description here.
%
\subsection{Project Description}
The main goal of the \projectname{} project is to create a ``virtual petri dish'' in which educators, students, and interested individuals without previous experience in AI/AL theory and without engineering degrees can simulate biological evolution in a fun, faster-than-life, and graphics-intensive environment.

This is the official project description from our project proposal (with modifications to keep it up to date):

\emph{``While there are already systems that are capable of doing evolutionary simulation, few are easy and/or fun enough to use for a high-school biology student. The ProtoVitae project aims to create a graphical, user programmable, artificial life and evolutionary simulation environment suitable for classroom experimentation. It will be composed of two parts: the gene editor, and the world simulator. The gene editor will allow non-professionals to script genes or traits that can be inherited by organisms. The world simulator will provide a stage for the organisms to simulate interactions associated with their genes (mating, killing, eating) in a faster-than-life environment, allowing the user to see what would happen to the various organisms.}

\emph{At this stage, team \emph{K.A.R.P.} is expecting to use a graphics engine to allow users to visually \emph{watch} what is happening in the environment. Team \emph{K.A.R.P.} would like to make the ProtoVitae project available to the public through open source licensing.''}

%
% *** Write the project goals here.
% Follow the format of the goal templates.
%
\section{Project Goals}
%-------------------------------------------
\goal%
{To develop a tool that is usable by high school students to simulate biological evolution.}% Goal
{There are no other ALIFE products that are geared toward non-technical or younger people.}% Advantage
{75\% of high school students should be able to use the \projectname software with no external assistance.}% Metric
%-------------------------------------------
\goal%
{To develop a tool that is flexible enough to provide a rich variety of simulation results.}% Goal
{Meaningful results will make the system valuable to students and educators.}% Advantage
{The variations between simulation results should differ\footnote{on average} by 25\% or more.}% Metric

\section{Stakeholders}
%
% *** Enter a list of stakeholders here:
%
\begin{tabular}{|l|c|}
  \hline
  %-------------------------------------------
  % Enter Type:
  Project Team & \parbox{.5\textwidth}%
  {~\\
  % List Names Here:
  Kieran Easter\\
  Adam Patterson\\
  Ryan J. Bovorasmy\\
  Paul Kratt\\
  }\\
  \hline
  
  Users & \parbox{.5\textwidth}%
  {~\\
  % List Names Here:
  High-School Students\\
  Interested General Public\\
  }\\
  \hline
  
  Senior Design Show Spectators & \parbox{.5\textwidth}%
  {~\\
  % List Names Here:
  MSOE Students\\
  Interested Companies (Industry)\\
  MSOE Professors\\
  }\\
  \hline
  
  Senior Design Advisors & \parbox{.5\textwidth}%
  {~\\
  % List Names Here:
  Dr. Welch\\
  Dr. Rothe\\
  }\\
  \hline
\end{tabular}

%
% *** Work context diagrams
%
% INSTRUCTIONS:
% In the following section, fill out the marked areas.
%
% Do not remove the comments; they are also used to
% allow the \work{}{}{}{} command to have line breaks.
%
% A complete row in the work context diagram is marked with a horizontal
% line composed of minus signs (------).
% Copy and paste from line to line to add more rows to the table.
%
% If there are more than a few rows, you may need to start a new table in
% order to break it up across pages.
%
\section{Work Context}
\includegraphics{work_context.png}\\{}\\{}
\begin{tabular}{|l|l|l|l|}
  \hline
  \textbf{Adjacent System} & \textbf{Category} & %
  \textbf{Inflow Events} & \textbf{Outflow Events} \\
  \hline
  %--------------------------------------------------
  \work%
  %
  % Adjacent System:
  %
  {User}%
  %
  % Category (Active/Automatic):
  %
  {Active}%
  %
  % Inflow Events:
  %
  {
    \begin{itemize}
      \item System Prompts
    \end{itemize}
  }%
  %
  % Outflow Events:
  %
  {
    \begin{itemize}
      \item User Input
    \end{itemize}
  }
  \\
  \hline
  %--------------------------------------------------
  \work%
  %
  % Adjacent System:
  %
  {System}%
  %
  % Category (Active/Automatic):
  %
  {Active}%
  %
  % Inflow Events:
  %
  {
    \begin{itemize}
      \item User Input
    \end{itemize}
  }%
  %
  % Outflow Events:
  %
  {
    \begin{itemize}
      \item User Prompts
    \end{itemize}
  }
  \\
  \hline
\end{tabular}

%
% *** Use case model inclusions.
%
% Name the files with descriptive names, rather than numbers.
% This way, you can change the order, and the numbers will be automatic.
%
\section{Use-Case Models}
%
%\input{} % Prepare for simulation, this is not complete as of 2007-11-01.
% 
\input{usecases/uc-prepare-simulation.tex}
\input{usecases/uc-perform-simulation.tex}
\input{usecases/uc-end-simulation.tex}
\input{usecases/uc-advanced-simulations.tex}

%\input{basic.tex} % Uncomment to build this SRS with basic use cases. This may be useful for creating the SDS.


%
% *** Assumptions
%
\section{Assumptions}
\begin{itemize}
  \item The user is familiar with computer GUI usage operations.
  \item The user has a basic understanding of the theory of evolution.
\end{itemize}

%
% *** Dependencies
%
\section{Dependencies}
\begin{itemize}
  \item The system requires JRE 1.6 or later to run.
  \item The system requires OpenGL hardware acceleration to run smoothly.
\end{itemize}

%
% *** Risks
%
\section{Risks}
%---------------------------------------------
\risk%
{Rapid Changes to Requirements}% Description.
{10-24-2007}% Last Updated.
{Medium}% Severity.
{Unlikely}% Likelihood.
{Solid commitment to SRS by both parties.}% Mitigation.
%---------------------------------------------
\risk%
{Project Dropped}% Description.
{10-24-2007}% Last Updated.
{High}% Severity.
{Very Unlikely}% Likelihood.
{Ensure that stakeholder input is requested and acted upon throughout the course of the project.}% Mitigation.
%---------------------------------------------
\risk%
{Developers Can Not Meet Time Requirements}% Description.
{10-24-2007}% Last Updated.
{High}% Severity.
{Somewhat Likely}% Likelihood.
{Developers shall cover each other when individual developers can not meet time requirements for any given cycle week. Developers shall conform to the contractual agreement in the project repository. This agreement imposes penalties on members that do not either 1) meet planned time or 2) do not complete their tasks, whichever has lower time. }% Mitigation.
%---------------------------------------------
\risk%
{Unequal Member Effort}% Description.
{10-24-2007}% Last Updated.
{Low}% Severity.
{Likely}% Likelihood.
{Other members shall pick up load or encourage other team members. Developers shall conform to the contractual agreement in the project repository. This agreement imposes penalties on members that do not either 1) meet planned time or 2) do not complete their tasks, whichever has lower time. }% Mitigation.
%---------------------------------------------
\risk%
{Software (API) Incompatibilities}% Description.
{10-24-2007}% Last Updated.
{High}% Severity.
{Unlikely}% Likelihood.
{Ensure that selected software is compatible from inception, stick with selected software, do not adopt new software after selection.}% Mitigation.
%---------------------------------------------
\risk%
{Third Party Update Incompatible}% Description.
{10-24-2007}% Last Updated.
{Medium}% Severity.
{Unlikely}% Likelihood.
{Ensure that third-party updates are not used, stick with older version.}% Mitigation.
%---------------------------------------------
\risk%
{OpenGL Integration Does Not Work as Expected}% Description.
{10-24-2007}% Last Updated.
{High}% Severity.
{Very Unlikely}% Likelihood.
{Ensure that OpenGL can be integrated into the product from inception. If not, switch technologies early on.}% Mitigation.
%---------------------------------------------
\risk%
{IDE Incompatibility During Development}% Description.
{02-16-2008}% Last Updated.
{Low}% Severity.
{None. As of 2-16-2008 all developers are using the same IDE.}% Likelihood.
{Ensure that all developers are familiar with all IDEs used for the project. In the case of incompatibility, switch development environment to conform to a single IDE.}% Mitigation.
%---------------------------------------------
\risk%
{Project is Unfeasible for Planned Time}% Description.
{02-16-2008}% Last Updated.
{High}% Severity.
{Somewhat Unlikely}% Likelihood.
{Plan time for each task and sub-task, take all developer schedules into consideration. If planned time is unfeasible, reduce scale of project. Developers shall conform to the contractual agreement in the project repository. This agreement imposes penalties on members that do not either 1) meet planned time or 2) do not complete their tasks, whichever has lower time.}% Mitigation.
%---------------------------------------------
\risk%
{Project structure change results in inability to compile due to broken dependencies}% Description.
{02-16-2008}% Last Updated.
{Moderate}% Severity.
{Somewhat Unlikely}% Likelihood.
{The NetBeans project files typically refer to external libraries by absolute path instead of relative. Delete the .properties files from the nbproject folder, and checkout the working copy currently in SVN. If that fails, try checking out the previous  revision. As a last resort, it may be necessary to recreate your copy of the project locally and copy over the source files.}% Mitigation.
%---------------------------------------------
\risk%
{Unable to adequately test and repair}% Description.
{05-03-2008}% Last Updated.
{High}% Severity.
{Somewhat Unlikely}% Likelihood.
{If a serious issue affects the program and cannot be resolved quickly, we may wish to develop use-cases that will avoid this issue during the senior design show as a last-resort.}% Mitigation.

%
% *** Constraints
%
\section{Constraints}
\begin{itemize}
  \item The system shall be compatible with Java 6 (JRE 1.6, JDK 1.6). 
  \item The system shall run as expected on Microsoft Windows XP SP2.
  \item The system shall run as expected on Microsoft Windows Vista.
  \item The system shall run as expected on Microsoft Windows 2000.
  \item The working first version of the system shall be created on or before May 23rd, 2008 (MSOE Senior Design Show).
  \item The system shall be created without directly spending any university resources.
\end{itemize}

%
% *** Open Issues
%
\section{Open Issues}
\begin{itemize}
  \item What will the traits look like?
  \item How will food and waste interact with the organisms?
  \item How will fighting take place?  Individuals or groups?
  \item How will genetic algorithms and the fitness function be integrated?
  \item What base traits will be in the organisms?
\end{itemize}

%
% *** Uncomment any subsections that you need in the following section:
%
\section{Requirements}
%============================================================================
% *** Functional Requirements
%
% For help on functional requirements, please see:
% http://en.wikipedia.org/wiki/Functional_requirements
%
% Another good book is "Mastering the Requirements Process, Second Ed." by
% Suzanne and James Robertson. Most of the requirements sections 
% below are described using passages from this book (Marked with [MRP]).
%
\subsection{Functional Requirements}
\newcounter{fr}
\begin{list}{FR\thefr{}}{\usecounter{fr}}
	\item The system's organisms shall be composed of traits.
	\item The system shall allow organisms to mate and create offspring based on the mating organisms' traits. 
	\item The system's organisms shall each have a set of exposed traits. 
	\item The system's organism's exposed traits shall each be composed of a maximum and current value.
	\item The systems's organisms shall each have a set of underlying traits.
	\item The systems's organism's underlying traits shall have the ability to affect the maximum values of an organism's exposed traits. 
	\item The system's organisms shall have the ability to feed.
	\item The system's organisms shall require food to survive. 
	\item The system shall allow for environmental effects to occur. 
  \item The system shall be modifiable to produce a large number of simulation results.\\
	\textit{All results will be dynamically created based on the options available to the user.}
  \item The system shall provide a mechanism for modifying organisms.\\
	\textit{An internal tool will exist in the system to load, edit and save organisms.}
  \item The system shall allow users to pause, speed up, slow down and resume simulation speed.
  \item The system shall allow users to follow an organism in the environment.\\
  \textit{User will be able to select an organism and the system will automatically follow it.}
  \item The system shall allow users to cancel actions and simulations at all reasonable times.\\
  \textit{Unless the simulation is busy performing a short task (less then 10 seconds), the user should be able to cancel the current operation.}
  \item The system shall allow users to create, modify, and use traits.\\
  \textit{The system will provide a scripting engine for the user to mainipulate their own traits.}
  \item The system shall allow user to manipulate the viewing area. \\
  \textit{It should be possible for the user to pan or zoom a large viewing area.}
\end{list}
% %============================================================================
% % *** Usability Requirements [MRP]
% %
% % Usability requirements are often left out of the requirements specification 
% % on the assumption that no sane programmer would build a product that is hard 
% % to use. At the same time, the product's usability might be one of the key 
% % factors that determine whether the intended users actually use it. Do not 
% % make the mistake of assuming the product will be usable; what is usable to 
% % one person could be unfathomable to another. Instead, write the product's 
% % usability requirements in a highly specific manner.
% % 
% % Usability requirements make the product conform to the user's abilities and 
% % expectations of the usage experience.
% % 
% % The usability and humanity requirements make the product conform to the 
% % user's abilities and expectations of the usage experience. Go to section 3, 
% % Users of the Product, of your requirements specification and look at your 
% % descriptions of the users, along with the classifications of their skill 
% % levels. What kind of people are they? What kind of product do they need to 
% % do their jobs? The usability requirements ensure that you make a successful 
% % product for them. (See Figure 8.4.)
% % 
% % The usability of a product affects productivity, efficiency, error rates, 
% % and acceptance of the new product. Carefully consider what your client is 
% % trying to achieve with the product before writing these requirements.
% % 
% % For example, you might have this usability requirement: 
% % "The product shall be easy to use."
% % 
% % At first this requirement may seem vague and idealistic, but remember that 
% % you will add a fit criterion to quantify just how "easy to use" the product 
% % is for your users. You could, of course, make the requirement much less 
% % ambiguous: 
% % "The product shall be easy to use by members of the public who might not 
% % read English." 
% % 
% % You could also revise it for a different user group: 
% % "The product shall be easy to use by certified mechanical engineers."
% %
 \subsection{Usability Requirements}
 \newcounter{us}
 \begin{list}{US\theus{}}{\usecounter{us}}
   \item The system shall have a low learning curve.\\
   \textit{75\% of high school students will need no outside help to begin using the application.}
   \item The system shall conform to a standard Windows look at feel.
	 \item The system's user interface shall be internally consistent.
	 % The user should find component manipulation options in a similar location throughout each window of the interface.
 \end{list}

% %============================================================================
% % *** Performance Requirements [MRP]
% % 
% % Performance requirements are written when the product needs to perform some 
% % tasks in a given amount of time, some tasks need to be done to a specific 
% % level of accuracy, or the product needs to have certain capacities.
% % 
% % The need for speed should be genuine. All too often we want things to be 
% % done quickly when no real need for speed exists. If a task is to produce a
% % monthly summary report, then there is probably no need to do it quickly. 
% % By contrast, the very success of the product may depend on speed: 
% % "The product shall identify whether an aircraft is hostile or friendly 
% % within 0.25 second."
% % 
% % Capacity is another performance requirement. For example, the client for 
% % the IceBreaker product wanted to sell it to road authorities around the 
% % world. These authorities are responsible for geographical areas of varying 
% % sizes, and the client needed to ensure that the product could handle the 
% % largest area covered by any potential client. Initially we would have 
% % written the requirement as follows: "The product shall accommodate the 
% % largest geographical area of any road authority in the world."
% % 
% % Of course, this is not a practical requirement to hand over to a designer, 
% % so eventually we refined it:
% % 
% % "Description: The product shall have the capacity for 5,000 roads.
% %  Rationale: The maximum number of roads in the area of any potential 
% %             customer for the product."
% %  
% % When you are thinking about performance requirements, consider such 
% % aspects as these:
% % 
% % + Speed to complete a task
% % + Accuracy of the results
% % + Safety to the operator
% % + Volumes to be held by the product
% % + Ranges of allowable values
% % + Throughput, such as the rate of transactions
% % + Efficiency of resource usage
% % + Reliability, often expressed as the mean time between failures
% % + Availability--the uptime or time periods when users can access the product
% % + Fault tolerance and robustness
% % + Scalability of most of the above
% % 
% % Performance requirements include the risk of damage to people or property. 
% % If your product is a lawn mower, then there is a genuine need for the 
% % product to avoid cutting off the user's toes. And Isaac Asimov included 
% % this in his laws of robotics: 
% % "A robot shall not injure a human being."
% %  
% % Hardware is not the only potential source of damage. You should consider 
% % whether your software product could cause damage, either directly or 
% % indirectly. The IceBreaker product schedules trucks to spread de-icing 
% % materials on roads. Because environmental damage from this material can be 
% % serious, the requirement covers this issue:
% % 
% % "Description: The product shall schedule de-icing activities so that the 
% %               minimum necessary amounts of de-icing material are spread on 
% %               roads.
% %  Rationale: To minimize environmental damage."
% % 
% % In some cases, you may want to specify a performance requirement for the 
% % outcome of a use case. For example, we found this performance-related 
% % requirement:
% % 
% % "Description: The product shall schedule de-icing activities so that the 
% %               rescheduled de-icing truck is estimated to arrive at the 
% %               breakdown location within 30 minutes of breakdown notification.
% %  Rationale: To resume de-icing as soon as possible."
% % 
% % The performance requirements come mainly from the operating environment. 
% % Each environment has its own set of circumstances and conditions. The 
% % people, machines, devices, environmental conditions, and so on all place 
% % demands on the product. The way your product responds to these conditions how 
% % fast it has to be, how strong, how big, how often dictates the appropriate 
% % performance requirements.
% %
 \subsection{Performance Requirements}
 \newcounter{pe}
 \begin{list}{PE\thepe{}}{\usecounter{pe}}
   \item The system shall have a consistent and reasonable frame rate on standard high school computers.\\
		\textit{A 1 GHz computer running Windows 2000 or XP should be capable of displaying a simulation smoothly.}
		\item The system's UI shall be reasonably responsive.\\
		\textit{When an action is performed by the user, they perceive the reaction from the program to be instantaneous.}
 \end{list}

% %============================================================================
% % *** Legal Requirements [MRP]
% % 
% % The cost of litigation is one of the major risks for software-for-sale, 
% % and it can be expensive for other kinds of software as well. You must make 
% % yourself aware of the laws that apply to your kind of product, and write 
% % requirements for the product to comply with these laws. Even if you are 
% % building software for use inside your own organization, be aware that laws 
% % applying to the workplace may be relevant.
% % 
% % Start with your company's lawyers. They have far more experience with the 
% % law than you. Here are several things that you can do to facilitate 
% % compliance:
% % 
% %     + Examine adjacent systems or actors. These are the entities that have 
% %       contact with your product.
% %     + Consider their legal requirements and rights. For example, are any of 
% %       the disabled-access laws applicable? Does the adjacent system have 
% %       any rights to privacy for the data that you hold? Do you need proof 
% %       of transaction? Or nondisclosure of the information your product has 
% %       about the adjacent system?
% %     + Determine whether any laws are relevant to your product 
% %       (or to the use case or the requirement). For example, are data 
% %       protection, privacy laws, guarantees, consumer protection, consumer 
% %       credit, or "right to information" laws applicable?
% % 
% % A legal requirement is written like this: "The product shall comply with 
% % the Americans with Disabilities Act."
% % 
% % You need help from your lawyers to know which law is applicable. The law 
% % itself may also specify its own requirements. For example, automated
% % products built for drug development use by the pharmaceutical industry 
% % must be self-documenting. The precise nature of this self-documentation 
% % varies. Nevertheless, you (or anybody writing requirements for these 
% % applications) have to understand that these legal requirements exist and 
% % write them into your specification.
% % 
% % You are required by law to display copyright notices, particularly if you 
% % are using other people's products. Take a moment to look at the splash 
% % screens of software running on your personal computer as an example 
% % of how this works.
% % 
% % Products are required by law to display warning messages if there is any 
% % danger that some dim-witted user might do the wrong thing with it. For 
% % example, a blanket made in a southeast Asian country carries this warning: 
% % "Warning: Do not use blanket as a hurricane shelter."
% % 
% % A label on a child's scooter reads: "This product moves when used."
% %
 \subsection{Legal Requirements}
 \newcounter{le}
 \begin{list}{LE\thele{}}{\usecounter{le}}
   \item They product shall be easily distributable to high schools.\\
	 \textit{A high school should not have to perform any process of due diligence to in order to obtain and use this software; i.e., the terms and conditions and all related legal information will be summarized and easy to understand.}
 \end{list}

% %============================================================================
% % *** Licensing Requirements
% % 
% %  Does the software need to have a specific license? Are there requirements 
% %  that must be considered for picking a license in the future?
% %
 \subsection{Licensing Requirements}
 \newcounter{li}
 \begin{list}{LI\theli{}}{\usecounter{li}}
   \item The product shall be distributed under the terms and conditions of the LGPG.
   \item The product shall be distributed free of any implied warranty or guarantee.
 \end{list}

% %============================================================================
% % *** Reliability Requirements
% % 
% % The following are typical examples of reliability requirements:
% % 
% %     * The application's mean time between failures shall be at least 1 
% %        month
% %     * The mean time between failures for the normal paths through the 
% %        purchase item use case shall be at least 4 months.
% %     * The component's mean time between failures shall be at least 1 
% %        year.
% %     * The probability that the component fails shall not exceed .001% 
% %        per year.
% %     * The component shall not fail more than an average of 3 times per 
% %        year.
% %
 \subsection{Reliability Requirements}
 \newcounter{rl}
 \begin{list}{RL\therl{}}{\usecounter{rl}}
   \item The system shall handle erroneous data and internal exceptions without crashing.\\
   \textit{Loading corrupted stored data will not cause the system to exit ungracefully.}
 \end{list}

% %============================================================================
% % *** Supportability Requirements [MRP]
% % 
% % Usually at requirements time you do not know exactly how much maintenance 
% % your product will undergo in its lifetime, nor do you always know the type 
% % of maintenance that it will need. However, we do have some products where 
% % maintenance can, to some extent, be foreseen. Consider whether any expected 
% % changes will occur in the following areas:
% % 
% %     + Organization
% %     + Environment
% %     + Laws that apply to the product
% %     + Business rules
% % 
% % Might other factors affect your product? If you know or strongly suspect 
% % that the product will undergo relatively heavy maintenance due to expected 
% % changes, then specify the types of expected changes and the amount of 
% % time allowed for those changes.
% % 
% % If you are creating a software product that should be able to run on 
% % several different types of operating system, then specify it:
% % 
% %  "Description: The product shall be readily portable to Linux.
% %   Rationale: This has been identified as a future growth market."
% % 
% % Keep in mind that your requirements document is a contract to build the 
% % product. You are saying to the developer that you want to be able to port 
% % the product to another platform at some point in the future, and that you 
% % will hold him accountable for the adaptability of the product to a new 
% % machine. When you attach the fit criterion to this requirement, you 
% % specify the characteristics of the machine and the expected time or effort 
% % necessary to make the transition.
% % 
% % The IceBreaker product had this requirement: 
% % "The product shall be translated into various foreign languages. 
% % As yet, the languages are unknown."
% % 
% % This requirement had a big effect on the product's designers. They designed 
% % the interface in such a way as to make it easy to add new languages. 
% % Also, they took into account the fact that different languages sometimes 
% % mean different cultures and different ways of presenting data.
% % 
% % Support requirements are also covered in this section of the requirements 
% % specification. In some cases your client may indicate that the product 
% % will be supported by the existing help desk, in other cases the product 
% % must be entirely self-supporting. By making this point clear at requirements 
% % time, you ensure that the designer builds in the appropriate mechanisms for 
% % contacting the help desk or providing answers for questions likely to 
% % arise with usage.
% %
% \subsection{Supportability Requirements}
% \newcounter{su}
% \begin{list}{SU\thesu{}}{\usecounter{su}}
%   \item A requirement.
% \end{list}

% %============================================================================
% % *** User Requirements
% % 
% % Requirements incorporated in from our user base, or from stakeholders, etc.
% % 
% \subsection{User Requirements}
% \newcounter{ur}
% \begin{list}{UR\theur{}}{\usecounter{ur}}
%   \item A requirement.
% \end{list}

% %============================================================================
% % *** Political and Social Requirements
% % 
% % Requirements incorporated in from our user base, or from stakeholders, etc.
% % 
 \subsection{Political and Social Requirements}
 \newcounter{ps}
 \begin{list}{PS\theps{}}{\usecounter{ps}}
   \item The system shall not teach evolutionary theory.\\
   \item The system shall not imply that evolutionary theory is correct.\\
   \textit{It should be made clear that the evolution of the system's simulated organisms does imply that large scale biological evolution acts in a similar fashion.}
 \end{list}

% %============================================================================
% % *** Software Requirements
% % 
% % These are requirements that explain what existing software systems will
% % need to in order to communicate with the system described in this document.
% % 
% % This includes API's, existing or legacy systems, etc.
% % 
% % Note that these are not referring to what software will be used to implement
% % the system, but instead, what software the new system will need to work 
% % with or be compatible with.
% % 
% % Examples:
% % 
% % + "The script extension shall be compatible with Microsoft Word 2007."
% % + "The application must be compatible with PostgreSQL v.xx and MySQL v.5"
% % + "The system shall be packaged with Google Desktop."
% %
 \subsection{Software Requirements}
 \newcounter{so}
 \begin{list}{SO\theso{}}{\usecounter{so}}
	 \item The system shall operate on JRE 1.6.
   \item The system shall operate on a standard Windows 2000, Windows XP SP2, or Windows Vista personal computer.\\
	 \textit{All PC's with Windows 2000, XP SP2 and Vista that have Java 6.0 or higher will be able to run this software.}
	 \item The system shall notify the user if their host machine is not compatible.\\
	 \textit{An error message will be displayed if it is not possible to run the program on the user's machine.}
 \end{list}

%============================================================================
% *** Applicable Standards
%
% This includes things like XML standards, etc. 
% What standards will be used when creating this system? 
% 
% + HTML 4.0? 
% + XHTML 4.0 Transitional? 
% + XML 1.0? 
% + ISO/IEC 14882:2003 Programming Language C++?
%
\subsection{Applicable Standards}
\newcounter{ap}
\begin{list}{AP\theap{}}{\usecounter{ap}}
  \item The system's underlying Java source code shall conform the the Java 6 standards and API (see \textbf{\textit{http://java.sun.com/javase/6/docs/api/}}).
  \item The system's underlying Java source code shall be documented using the Javadoc 1.5 
        standard (see \textbf{\textit{http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/index.html}}).
  \item The system's underlying XML documents shall conform to the fourth edition WC3 XML 1.0 recommendation (see \textbf{\textit{http://www.w3.org/TR/REC-xml/}}).
  \item The system's user documentation shall be written accoring to the second edition W3C XHTML 1.0 recommendation (see \textbf{\textit{http://www.w3.org/TR/xhtml1/}})
  \item All applicable resulting XML transformations to a human-readable format shall conform to the second edition W3C XHTML 1.0 
        recommendation (see \textbf{\textit{http://www.w3.org/TR/xhtml1/}})
\end{list}

\end{document}